\documentclass[]{article}
\usepackage{hyperref}
\usepackage{graphicx}

\begin{document}
\title{How's The Weather?\\ \normalsize{Enterprise Application Integration Project}}
\author{A. Andronikakis, D. Dobreva, C. Halmaghi, Zs. Istvan}
\date{\today}
\maketitle

\section{Presentation}
Our projects aims at solving the problem of weather forecasts not
being accurate and ``localized'' enough. Currently, the weather
condition returned by the online services is based on how the weather
is at the closest measurement station, which is usually located at the
nearest airport. 
This, however, may be tens of kilometers away from the actual location of
the end user. In order to solve this problem, we propose a social
platform that provides a more accurate forecast based on what
other people around the end user are experiencing.

Our service also proposes points of interest to the end user in a
context-sensitive manner. That is, it will propose outside activities
(like golf) for sunny weather, but in case it is raining, it will list
possible indoor activities (bars, shopping).


\section{Work Distribution}
Our project is based on web services offered by
Microsoft\footnote{\url{http://dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc}}\footnote{\url{http://dev.virtualearth.net/webservices/v1/searchservice/searchservice.svc}}
for geocoding, reverse geocoding and point of interest search,
and a free weather reporting
service\footnote{\url{http://www.webservicex.net/globalweather.asmx?WSDL}}.
The server side of our application wraps the stubs (created by AXIS2) of these services
in service objects, provides a ``status store'' to keep track of the
weather at given coordinates, and exposes its functionality as a
SOAP-based web
service.
The client (also using AXIS2) accesses the server through an
object-interface, and offers an easy to use web-portal for users.

\begin{figure}[htp]
\begin{centering}
\includegraphics[scale=0.17]{fig/web_service_abstract.eps}
\caption{High level view of our project}
\end{centering}
\end{figure}

The initial design and the milestone definitions of our project were planned
together, after which each member was assigned a part of the ``pipeline''
he/she would be responsible for:
\begin{itemize}
  \item Zsolt -- wrapper for web services, storage and retrieval of weather statuses
  \item Alex -- server-side that puts together the wrappers and
    exposes itself via WSDL
  \item Denitsa -- client-side that consumes the interface, and
    provides a web-interface
  \item Catalin -- handlers in both client- and server-side for
    various operations
\end{itemize}

In the following, we will present the main design decisions taken and
difficulties encountered in each of the four parts.

\section{Web Services}

\input{zsolt.tex}

\section{Our Service}

\input{alex.tex}

\section{Client}

\subsection{Logic}
Our client is a simple web portal. It offers basically 5 different use cases:\\
\begin{itemize}
  \item Check Weather by address -- Here the user sees a prompt to
    type his full address. It consists of street, ZIP code, town and
    country and then he just has to press the button 'Get
    Weather'. After sending the request to the server there are three
    possibilities of what could happen. If the user address is
    resolved to a single location then the user receives the weather
    condition and points of interest if such are found. If the address
    is resolved to more than one location then the user is presented
    with a list of addresses and is prompted to choose one. After that
    follows again the case where the weather status and eventually
    POIs are presented. The third possible case here is when for the
    given address nothing is found by the service. Then the user
    receives a message that nothing is found. In this case normally
    the problem is that the address given by the user is not full and
    he/she has to add something like ZIP code if not present.

  \item Check Weather by GeoLocation -- This case has the same
    possible outcomes as the previous one but because of the nature of
    GeoLocation coordinates, it is almost impossible that the
    GeoLocation is resolved to more than one location or that it is
    not found (if the given coordinates are correct). Therefore what
    would happen here after typing the latitude and longitude is that
    weather status and found POIs are presented.

  \item Weather feedback  by address -- When the user wants to give a
    weather feedback using his/her address he/she will select first
    the Weather feedback tab and then the Give address menu-tab. In
    this case the user has to type again a full address with street,
    ZIP, town and country if all known and provide a weather
    status. The weather status is not a fixed set of words. We decided
    to give the end user the chance to type whatever he wants but
    after that a handler filters this status by searching for a
    keywords. More about the message handler is provided in the next
    section of the report. After submitting the address and the status
    the user is presented with a message that the status was submitted
    successfully or with list of possible addresses if the user
    address was resolved to more than one location.  

  \item Weather feedback by GeoLocation -- This use case is the same
    as the previous one only that the user has to type here his/her
    geological coordinates.

  \item About Us -- We provide here a short information about us.
\end{itemize}

\subsection{Implementation}

The client side communicates with the service using SOAP messages. It
wraps the stub created by AXIS2 in a service proxy object called
respectively ServiceProxy. This java object provides 4 different
methods, which serve the 4 different functionalities provided by the
service.  
\begin{itemize}
  \item getProposalsByAddress(String address) 
scr  \item getProposalsByGeoLocation(String x, String y)
  \item setWeatherStatusByAddress(String address, String status)
  \item setWeatherStatusByCoordinates(String x, String y, String status)
\end{itemize}

Each of those methods is using the stub object to make a call to the
service and gets a ResponseMessage object as a result. This object was
described in a previous section.


To bind together the functionality wrapped in the service proxy and
the user calls in the jsp files we decided to use a java servlet
because it offers much easier maintenance of the code. In the jsp's we
make Ajax call to the ResultServlet which extends the HttpServlet
class. This object then serves as an intermediary object to the
service proxy. It makes the call to all 4 different methods according
to the type of action which it receives from the HttpServletRequest
object.


To process the ResponseMessage object's data back to the jsp files we
decided it is best to use JSON objects. This is a very simple and
efficient way. As properties in the JSON object we put the response
messages, status code, venues, weather status and list of addresses
received from the service call. 


\subsection{Challenges}

One of the biggest challenges with Web portals is to make them look
and work in every possible browser in the same way. This is not a
trivial problem as each browser is differs from the standard in it's
own way. The decision we have taken to cope with this is to use jQuery
as it offers a unified, browser independent interface and also
simplifies our source code. We have used jQuery for applying themes to
our GUI and also for doing Ajax.

\section{Message Handlers}

\input{catalin.tex}

\end{document}
